ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group98b.txt/000065_icon-group-sender _Thu Jun 4 08:05:51 1998.msg

Internet Message Format | 2000-09-20 | 6KB

Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
    by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id IAA20190
    for <[e-mail]>; Thu, 4 Jun 1998 08:05:50 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
    id AA11122; Thu, 4 Jun 1998 08:05:42 -0700
Date: Thu, 4 Jun 1998 14:20:21 +1200 (NZST)
From: "Richard A. O'Keefe" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Directory access facilities
Errors-To: [e-mail]
Status: RO
Content-Length: 5259

In reponse to messages like

    >I'd prefer a simple built-in function that would generate the names
    >of the files contained in a directory, e.g.
    > contents(s)
    >with other mechanisms (if any) used for finding attributes.

and

    I agree with you here, Gregg.  Probably need to, as a minimum, add a second
    function to determine if a given string refers to a directory name.
    Something like:

I'd like to say that people seem to have missed the point of my reference
to Tcl/Tk.  The point is that there is an *existing* *multiplatform*
implementation of this idea that *works*.  We don't have to design.
We can steal.

The *last* thing we have any shadow of an excuse for doing is bodging
together yet another incompatible design by appealing to "preferences".

Of course Tcl/Tk isn't the only thing around that one might reasonably
copy.  There's the POSIX 'glob' function, for example, which is given
a pathname with wilcards and some options, and returns an array of
strings (in which any character whatsoever except \0 may occur).  One
could have a very nice interface _based_ on glob(3c) + stat(2); any
platform offering FindFirst/FindNext can emulate glob() easily enough.

Nevin Liber wrote:

    I would also vote against filtering out "." and ".."; dir() should return an
    accurate representation of what is in the directory, and not require any
    special casing (and it is trivial to filter this out at a higher level).

But where did you get the idea that the presence of "." and ".." was 'an
accurate representation of what is in the directory'?  There are POSIX
implementations that go to some trouble to fake these entries because the
_real_ directory format _doesn't_ have them.  Do you want to filter them
out when you know they've been faked and include them when you know they
haven't?  It's better if they are _always_ present or _always_ absent
whatever is really on the disc.  Note that the POSIX.1 standard (ok, so I
have an old copy) says very clearly and explicitly

    5.1.2.2
    43  The readdir() function shall not return directory entries
        containing empty names.
===>    44  It is unspecified whether entries are returned for
        dot or dot-dot.

    B5.1.2
    2956 The directory entries for dot and dot-dot are optional.
         POSIX does not provide a
    2957 way to test a priori for their existence because
         an application that is portable
    2958 must be written to look for (and usually ignore)
         those entries.

There really are "POSIX" systems where those things AREN'T on the disk.
And of course there are non-POSIX systems that don't use "." or ".."
for anything particular.  Indeed, there's one file system I retain
considerable fondness for where the directory namespace and the file
namespace are disjoint, so that the same name _can_ be used for a directory
and a file at the same time, and often is.  E.g.
    (MAT212X)THESIS/PLOTTER/SOURCE ON USERPACK    => Algol source form
    (MAT212X)THESIS/PLOTTER ON USERPACK         => executable code
where .../PLOTTER is a file name and .../PLOTTER/ is a directory name.
To the best of my knowledge there isn't any Icon implementation for that
machine, but there's a standard C compiler and a near-enough-to-POSIX
OS interface, so there _could_ be an Icon implementation.

This _does_ count as a criticism of 'imitate Tcl/Tk' and 'imitate POSIX'
because it strongly suggests that separate functions for finding
directories and finding files would be appropriate.  (That's the way I
did it for Quintus Prolog, with
    file_member_of_directory(Directory[, Pattern], File)
    directory_member_of_directory(Directory[, Pattern], SubDir)
    file_property(File, Property, Value)
    directory_property(Directory, Property, Value)
operations.  Mind you, that had to be portable across MacOS, MS-DOS,
Unix, VMS, VM/CMS, MVS, and Xerox Lisp (XNS) so it was a bit more
portable than Icon may need to be.)  As I've hinted above, we could
patch around this particular problem by insisting that directory names
always end with a (native) separator and file names not; this will work
straight out of the box on many UNIX systems where dirname/ is equivalent
to dirname/., but can reasonably be faked anywhere, so a single interface
will do.

One particular point about citing Tcl/Tk is the file license.terms in
the Tcl8.0 distribution, which says amongst other things

    The authors hereby grant permission to use, copy, modify,
    distribute, and license this software and its documentation
    for any purpose, provided that existing copyright notices
    are retained in all copies and that this notice is included
    verbatim in any distributions.  No written agreement, license,
    or royalty fee is required for any of the authorized uses.
    Modifications to this software may be copyrighted by their
    authors and need not follow the licensing terms described
    here, provided that the new terms are clearly indicated on
    the first pagev of each file where they apply.

What this means is that if the Icon interface is based on the Tcl/Tk
interface, two important benefits follows:

    - a multiplatform interface which is *known* to be usable will
      be available for very little design effort
    - a multiplatform *tested* implementation will be available *free*.

I must ask:  why reinvent what we can steal?